14 April 1998
Source: HTML file from Martin Minow

See related files at Peter Junger's Web site: http://samsara.LAW.CWRU.Edu/comp_law/jvd/

Documents of the suit: http://jya.com/pdj.htm


GINO J. SCARSELLI (0062327)
664 Allison Dr.
Richmond Hts., OH 44143-2907
(216) 291-8601

RAYMOND VASVARI (0055538)
1201 Superior Building
815 Superior Ave. East
Cleveland, OH 44114-2702
(216) 622-1780

KEVIN FRANCIS O'NEILL (0010481)
Assistant Professor of Law
Cleveland-Marshall College of Law
1801 Euclid Ave.
Cleveland, OH 44115
(216) 687-2286

UNITED STATES DISTRICT COURT

NORTHERN DISTRICT OF OHIO

EASTERN DIVISION

PETER D. JUNGER

          Plaintiff

          v.

WILLIAM DALEY, et al.


         Defendants


______________________________________
)
)
)
)
)
)
)
)
)
)
)
)
)
Case No. 96 CV 1723


JUDGE NUGENT


DECLARATION OF
MARTIN MINOW

I, MARTIN MINOW, declare as follows:

1.      I am a senior software engineer at Apple Computer, Inc., 1 Infinite Loop, Cupertino, CA 95014. At present, I work on the input-output interface software for Apple's proposed new operating system that is code-named "Rhapsody." My areas of expertise within Apple include hardware interface software libraries called "device drivers," particularly the Small Computer Systems Interface (SCSI) driver, Apple's Open Collaboration Environment (AOCE), and operating system support for Apple and third-party developers. I give this declaration in my personal capacity and not on behalf of Apple Computer.

2.      I received my Bachelor's and Master's degrees from the University of Illinois, majoring in speech and linguistics, and received a fil. kand. (Master's) degree in phonetics from the University of Stockholm. While at the University of Illinois, I also held teaching and research assistant positions. I am a fluent speaker of Swedish, co-translator of two books, two movie subtitles, author of several articles in Swedish, and have edited several substantial technical translations.

3.      Before joining Apple in 1992, I was employed by Digital Equipment Corporation, starting in 1972, first in Stockholm, Sweden, and subsequently at several Digital sites in Eastern Massachusetts. While in Sweden, I wrote custom software for SAAB, Volvo, The University of Uppsala, and Outokumpu OY, a Finnish mining company. Much of this software dealt with very low-level hardware interface issues, including safety-critical software for recording aircraft flight-testing. Software written for Outokumpu was installed at copper and nickel mines in Finland, The Soviet Union, and the United States. I was also the lead software engineer for Digital's DECtalk speech synthesizer, designing its operating system, and many of the non-linguistic software modules. The DECtalk speech synthesizer is considered the "gold standard" for all English text-to-speech software. I am co-author of U. S. Patent 4,552,992 for work done on DECtalk. Other software engineering work at Digital included device drivers for several Digital operating systems and hardware devices. I am also a co-author of Decus C, a publicly-distributed C compiler for PDP11 systems where I wrote the pre-processor, part of the code generator that creates the output object code, the run-time libraries, many utilities and the documentation. Decus C was one of the first non-Unix C compilers and was one of the most popular programs in the Digital Equipment User Society (DECUS) software library.

4.      I am fluent in a number of computer programming languages, particularly C and Java. During my career, I used many other high-level computer languages, including Algol-60, MAD, Fortran-II, Fortran-IV, PL/I, PL/360, Snobol-3, Snobol-4, BASIC, BASIC-PLUS, RPG-2, and Mumps. I also used assembly language for the Illiac, Illiac-2, TRASK, IBM 1401, IBM 7090, IBM 7094, and IBM 360; Digital Equipment PDP-8, PDP-11, and VAX; Motorola 68000; Intel 80186; and IBM/Motorola Power-PC architectures.

5.      I originally learned to program on the Illiac computer, a machine with vacuum tube architecture that is an early example of the class of machines generally called "von Neumann Machines;" a class that also includes almost all of the general purpose digital computers used today. Von Neumann machines are characterized by a Central Processing Unit ("CPU"), a memory unit that contains both the instructions to be executed and the data that is to be processed by those instructions. Both instructions and data are coded in binary digits. One of the most significant characteristics of von Neumann machines is that they can treat their instructions as data, and thus modify their programs during execution. This is seen in the sample Illiac program annexed as Attachment A. One consequence of this is that there is no firm distinction between a program and the data it processes.

6.      The Illiac was in service from 1952 through 1962. Although, like all von Neumann machines, the instructions and data were processed in pure numeric form, its programs were generally written in pure numeric (hexadecimal) format or in numeric format with symbolic addresses (SADOI). Because Illiac programs were necessarily self-modifying, programmers were required to read and understand the numeric (hexadecimal and binary) memory format, and to interpret instruction sequences given their numeric form. Thus, I originally learned to program using the Illiac's "machine language," the actual numeric format that was executed by its CPU. The program in Attachment A is an example of a program written in Illiac's machine language.

7.      This example makes clear that "pure" machine code can be, and has been since the days of the earliest computers, used as a means of communicating information to human beings as well as for direct control of a computer system. Attachment B, for example, includes an article in Risks Digest describing a flaw in the Intel Pentium architecture (where an undocumented instruction halts the processor) and includes a number of very short samples illustrating how to write "pure" object code. This Illiac example also shows that pure machine code can be rendered into English with a minimum of effort. (Although I have not looked closely at Illiac code for well over 30 years, it only took about 20 minutes to write the explanation section.) This example also shows how Illiac programs must modify their internal instruction stream; the "42 8L" instruction at instruction location 1 stores the caller's return address within the "link" instruction at instruction word 8. When this instruction "22 F" is executed, it will jump to the caller's return address. In order to debug Illiac software, programmers like myself must be fluent in the pure numeric format, that is, the machine language or object code, that is used directly by the machine's CPU.

8.      I have written programs, or parts of programs, in machine language on many occasions: (i) The TRASK computer was a Swedish variant of the "von Neumann" architecture used by Illiac. While in Sweden, I programming the TRASK computer primarily in Algol-60. To aid my work on the TRASK computer, I wrote several small library routines in pure numeric form. (ii) As part of my work at Digital Equipment, I translated a small bootstrap program from internal machine numeric form to "pure" binary in order to hand-program a read-only module. An assembly language listing of this bootstrap is provided as Attachment C. (iii) An important part of my work as a software specialist at Digital Equipment consisted of reading memory dumps from customer machines that had failed. It was my task to determine the cause of failure: whether it was due to a program bug, hardware error, or operating system error. I also used this expertise to validate code sequences generated by the Decus C compiler. As part of my work as lead support engineer for the RSTS/E timesharing system, I helped design a software patching mechanism that let Digital distribute small corrections in object code form. In some cases, I distributed these patches by letter, telex, and by telephoning operators at affected sites and reading the object code patch over the phone.

9.      Since computers can manipulate computer programs just as they manipulate other data, it was not long after the creation of the first von Neumann machines that programs, (called "compilers," "interpreters," and "assemblers") were written that converted other programs written in a higher-level language, i.e., source code, into the numeric codes used directly by the computer's central processing unit. The original source code cannot be executed by a computer: only object code, the machine instructions themselves, is directly executable. The original source code is humanly readable. Two of my programming articles that include source code alongside English are found in Attachment D and can be downloaded from the World Wide Web. Moreover, good programmers write code that is easily understood by humans even if the net effect is a slight loss in the efficiency (speed) or size of the resulting program. This "best practice" includes avoiding certain constructions even when they can provide faster execution. For example, in my current work of writing a SCSI bus adaptor device driver, I used an object-oriented approach that simplified my programming effort even though a major part of the interface, the "interrupt service routine" required 30 microseconds more than it would require had I used a more direct approach.

10.      As an integral and essential part of my work as a software engineer, I have read and written object (machine) code without assistance from compilers and disassemblers. For example, in 1977, I used this ability to diagnose and repair systems at, among other sites, an American cotton mill. There, the customer did not provide an accurate listing of a customer-written hardware interface device driver. I used information in a numeric memory dump and a hardware logic analyser to locate the problem, and wrote a patch (a small correction sequence) in numeric object code that I used to modify the operating system and repair the customer's system.

11.      As a professional software engineer with over 30 years experience, I write a considerable amount of software to demonstrate engineering techniques, using these samples as an integral part of the documentation for new algorithms. Although this software would actually run when loaded into a computer, it was written primarily to be read by human beings, rather than to be executed by a machine. Even when software is written primarily to be executed, it is useful for it to still be readable by a human being to facilitate debugging and maintenance.

12.      I see no intrinsic distinction between high-level languages such as Fortran or C and the object code that directly controls the actual computer hardware. In some cases, such as the problem at the cotton mill related in paragraph 10 above, I must ignore the high-level language and rely exclusively on the object code in order to determine why the computer's actual operation disagrees with the operation the programmer intended. Moreover, many computer languages, including BASIC, JAVA, and PERL have no object code that can be directly executed. Instead, they are interpreted, either directly from the source code, or from an intermediate "virtual machine" representation. In these languages, particularly BASIC and PERL, the publication format (source code) is identical to the execution format.

13.      Although source code, especially in a high-level language such as Fortran, is significantly easier to read and write than object or machine code, it is often necessary for a programmer to read and write object code to use features that cannot be used from the high-level language, or when working with a hardware architecture, such as a programmable SCSI bus adaptor, for which no high-level language is available. Furthermore, when diagnosing hardware and operating system errors, there may be no information available other than the pure numeric data itself. Fortunately, there are today computer programs that can assist in this process; decompilers and disassemblers that take numeric machine code as their input data and that convert this data into assembly or a higher-level language. Source code, however, is not indispensable to the process of enhancing or debugging executable code. While source code is generally helpful, it is neither indispensable nor, in some unusual cases, appropriate. For example, if you are tracing a hardware error or looking for a Trojan Horse routine, you may wish to reconstruct the algorithm from the actual executable code to determine what the program actually does, rather than what the source code says it does.

14.      Based on my professional experience, both as a linguist and as a computer programmer, as outlined above, it is clear to me that all computer language, specifically including the object code that directly controls the computer hardware, is a form of speech that, while much simpler than human speech, shares the same overall form and structure, including symbols, syntax, expression, semantics, and shared social context that are necessary for human communication.

15.      "Science is, in one sense of the term, the set of symbols that scientists use to communicate their knowledge to other scientists. These symbols are published in journals and books and tables, and the symbols of one generation are studied by the scientists of the next." (George Miller, "Language and Communication" McGraw-Hill 1951, reprinted 1963). More and more, the symbols that scientists use to communicate their knowledge to one and other are the symbols of computer languages constrained by the syntax of those languages.

I declare under penalty of perjury under the laws of the United States that the foregoing is true and correct and that this Declaration was executed at __________________, on this the ___ day of _____________, 1997.

____________________________

MARTIN MINOW

Attachment A

This is a square root algorithm from "A Guide to Illiac Programming" by L. D. Fosdick, published by the University of Illinois Digital Computer Laboratory in 1961 (page 379-380). The columns labelled Location, Order, and Notes are, except for formatting, identical to the original Illiac documentation. The Explanation column is a contemporary description of the Illiac instructions. It should be noted that the numeric values (hexadecimal digits) from 10 (decimal) to 15 (decimal) are represented by the letter sequence "K, S, N, J, F, L" instead of the A to F sequence used today. The "K, F, or L" at the end of each line signals address translation to the paper-tape loader. Also, note that Illiac registers contain 40 bits of data, rather than the 32 generally used today. This square-root function is entered with the high-order argument in the A register and an eventual low-order argument in the memory word at location zero. In the order (instruction) column, note that values ending with 'F' refer to absolute memory locations, while values ending with 'L' refer to instructions locations offset from the start of the subroutine.

LOCATION   ORDER           NOTES           EXPLANATION
           00 K (R1)                       Library header information
   0       40 1F                           Store a Store argument in location 1
           K5 F                            Get caller return address
   1       42 8L           Plant link      Store return address in instruction 8
           51 1F                           Read argument into Q register
   2       10 1F           x0 = a/2 + 1/2  Right-shift A, Q 1 bit
           SJ F                            A = Q + 1/2 (rounding)
   3       40 2F           From 7  to 2F   Store A in location 2
           50 F                            Put location 0 into Q register
   4       L5 1F           a to A and Q    Put location 1 into A register
           66 2F                           Divide A, Q by  location 2
   5       S5 F                            Put Q register (quotient) into A
                                           register
           L0 2F           xn+1 - xn to A  Subtract location 2 from A register
   6       10 1F                           Right-shift A, Q 1 bit
           36 8L           End test        If A reg >= 0, goto instruction 8
   7       L4 2F                           Add location 2 to A register
           26 3L           Re-enter loop   Jump to instruction 3
   8       L5 2F           sqrt(A) to A    Put location 2 (result) into A register
           22 F            by 1    Link    Subroutine return (stored by
                                           instruction 1)


[End]